Legacy System Anti-Patterns and a Pattern-Oriented Migration Response

Mature information systems grow old disgracefully as successive waves of hacking result in accidental architectures which resist the reflection of on-going business process change. Such petrified systems are termed legacy systems. Legacy systems are simultaneously business assets and business liabilities. Their hard-won dependability and accurate reflection of tacit business knowledge prevents us from undertaking green-field development of replacement systems. Their resistance to the reflection of business process change prevents us from retaining them. Consequently, we are drawn in this paper to a controlled pattern-oriented legacy system migration strategy. Legacy systems exhibit six undesirable anti-patterns. A legacy system migration strategy must focus upon the controlled elimination of these anti-patterns by the step-wise application of six corresponding desirable patterns. Adherence to this migration strategy results in adaptive systems reflecting purposeful architectures open to the on-going reflection of business process change. Without such a strategy there is a very real danger that legacy system migration will occur all too literally. That is, the old legacy system will be migrated to a new legacy system albeit it one using the latest buzzwordcompliant technology. 1. Legacy Systems: Assets and Liabilities Organizations deploy information systems to support their business processes. As circumstances change, organizations adapt their business processes in response. Consequently, the supporting information systems must be adapted to track this business process change. Unfortunately, mature information systems tend to grow old disgracefully. Although an information system may begin its life with a flexible architecture, repeated waves of hacking tend to petrify mature information systems resulting in inflexible accidental architectures. Such architectures emerge "... more from the ingenuity of the systems developers' ability to 'warp' the code than from any purposeful design. As successive waves of hacking warp the information system further and further, its accidental architecture becomes more and more convoluted, and the intellectual capability of the developers to identify and apply clever hacks diminishes to a point at which the system is declared un-maintainable." [Lauder and Lind, 1999c]. This process of petrification, then, makes it increasingly difficult to modify a mature information system to reflect on-going business process change. A system which has undergone petrification is termed a legacy system [Brodie and Stonebraker, 1995]. Organizations are afraid of keeping their legacy systems, since maintaining them is a significant drain on the organization's resources. They are, however, also afraid of replacing them since those legacy systems have undergone years of debugging effort. As a consequence of this debugging effort they have grown to support not just explicitly understood business processes but also tacit business knowledge central to the smooth operation of the organization yet implicitly rather than explicitly acknowledged in the day to day activities of the business. A legacy system, then, is both a business asset and a business liability [Lauder and Lind, 1999c]. They are assets in sense that, through years of debugging effort they have grown to reflect essential tacit knowledge. They are liabilities, however, in that it has become increasingly difficult to adapt them to reflect ongoing business process change. To support a living [Morgan, 1996], learning [Senge, 1990], organization successfully, we must maintain the hard-won reflection of tacit business knowledge which makes legacy systems into assets, whilst simultaneously striving to eliminate the resistance to reflecting on-going business process change which makes those same systems into business liabilities. 1.1 Accidental Architecture Anti-Patterns We have been commissioned by a mid-sized software development organization to examine their legacy systems and determine what undesirable properties underlie their resistance to reflecting on-going business process change. Having examined these systems, it has emerged that their accidental architectures are characterized by a number of undesirable properties, which can be grouped into six general "anti-patterns":